IBIS Macromodel Task Group Meeting date: 14 February 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi * Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Walter noted that he would like five minutes to discuss BIRD 189. ------------- Review of ARs: - Walter noted that he had asked everyone to review the updated file naming rules document, BIRD 186.1. Bob R. had sent it to the ATM list for review. - Bob R. noted that at the last Open Forum meeting BIRD 147 had been sent back to ATM for review. Radek had suggested that one sentence detailing a potential work around a tool that didn't support the BIRD was unnecessary. Bob Miller had agreed. Arpad noted that Vladimir was attending so we could review some of his questions as well. - Arpad to help Fangyi with introducing the equation notation to the Flow BIRD. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - The February 7th minutes were not prepared and posted in time for the meeting. Minutes for January 24th were reviewed, as they had not been ready for the February 7th meeting. - January 24th minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Bob R.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 147 Discussions: - Arpad: Bob M. and Vladimir could discuss the private emails they've had regarding some of Vladimir's questions. - Bob M.: [sharing the email] - Question: Do all the AMI parameters files used by the AMI models need to explicitly specify AMI_Version 7.0 in order for EDA tools to consider back- channel communication mode, or is it enough to make sure that all the AMI models define the same protocol and have all other required parameters set properly? - Bob M.: My only answer is that the parser will fail if it sees these new reserved AMI parameters for BCI in an AMI file with a revision prior to when this BIRD is introduced. - Discussion: Walter noted that some EDA tools are already dealing with these parameters as model specific parameters. If the model's AMI file contains the model specific parameters then some tools will support them. The EDA tools need only pass in the user selected values for some In parameters (note: BCI_State is an InOut, however). Walter noted that the goal was to minimize the EDA tool's involvement. He noted that one thing the EDA tool did to make the process easier was to automatically provide the BCI_ID value to all models on the same channel, but this was not required. Walter said this had been designed with minimal EDA tool involvement so model makers like Bob M. could proceed with some back-channel work prior to tools supporting the BIRD. Vladimir noted for clarification that for now we had a temporary workaround of using these parameters as model specific, but starting from 7.0 (or when this BIRD is adopted) these would become Reserved parameters. Arpad noted that this was similar to the BIRD 158 situation, in which some models were being released with BIRD 158 parameters in the model specific section and those would be Reserved when and if BIRD 158 becomes part of the spec. Walter agreed. Vladimir asked why we needed this BIRD at all if it could be done currently with model specific parameters. Ambrish noted the BIRD fully defined several parameters that allowed the EDA tool to control training time, abort the simulation, monitor training progress, etc., and provided a first step toward generalizing a solution for back-channel. He said that without this BIRD we had no generally defined and recognized way for tools to support back-channel. Bob R. noted the general purpose of adding Reserved parameters so that their meaning is fully defined by the specification and every tool knows exactly how they should be utilized. After this discussion Vladimir noted that he might re-formulate some of his questions and resubmit them later. - Bob M.: I want to mention one other question of Vladimir's I found interesting. - Question: It looks like no training is allowed when communicating the modified impulse responses between Init() calls, only GetWave() may implement model communication? - Discussion: Bob noted that this was a true statement. Nothing prohibits the Tx or Rx from leaving a BCI message in the file after Init(), but the Rx has no means of communicating information back to the Tx before the first Tx GetWave(). Bob noted that there had been concerns about how training during Init() might modify the flow for the tool. Ambrish also noted that there had been other concerns about complicating the messages left in the BCI file itself. So, in general, this BIRD deals only with GetWave() based optimization. - Bob M.: I've submitted BIRD 147.6, with the only change being the deletion of the work-around sentence "If an EDA tool does not use BCI_Training_UI ...", as we discussed. - Mike L.: I received that submission. I will get it posted. - Walter: Motion that ATM recommends that the IBIS Open Forum pass BIRD 147.6 for inclusion in the next significant release of IBIS. - Ambrish: Second. - Arpad: Anyone opposed? [none] - I will send an email to notify the Open Forum. BIRD 186.1: - Walter: Did anyone have any questions about 186.1 after reviewing it? - Walter: Motion that BIRD 186.1 be submitted to the IBIS Open Forum with a recommendation from ATM that it be passed. - Bob M.: Second. - Arpad: Anyone opposed? [none] - Bob R.: I will submit it to the Open Forum. - Arpad: I will also send an email to notify the Open Forum about this one. BIRD 158: - Walter: Radek has gone through a re-write of this. - We should defer until Radek is here. Single Ended Applications of AMI: (DDR5 coming soon) - Arpad: Do we need anything in the spec for this? - Walter: Last week I made the statement that there's nothing we have to do in IBIS to handle single ended channels. - It came up because at the DesignCon Summit Fangyi brought up common mode issues with single ended channels (DDR4, DDR5, etc.). - I suggest we table this until Fangyi is here. - Ambrish: It was also mentioned at the DesignCon Summit that there is no place in the spec that says we can't do single ended. - The spec currently mentions that we can do both. - There may be something else we have to add, but as of now it's a raw analog waveform which is passed to the model, and we do handle it. - Walter: Specifically, we are talking about IBIS AMI on DDR4 DQ models. - Ambrish and I agree that we should wait for Fangyi. - Bob R.: Question for Randy, for single ended applications would you expect to see an s2p models. - Randy: I think you could be modeling a full channel with coupling, or if you do a single DQ at a time it might be an s2p. - Another complication is that the clock is not embedded. We need to simulate a strobe too. - Walter: Another answer to Bob's question is that when we say DDR5 (or maybe DDR4, too) for single ended the channels will be SPICE models and may include s2p. We're not sure if the driver itself is going to need a Touchstone option. It's not clear because the DDR5 spec hasn't been written yet. However, DQS, the strobe is really not true differential but two single ended DQ buffers. It's not clear about the routing, so they may use s4p or s2p. - Ambrish: Do we even need an AMI model for the strobes? - Randy: Yes, because it will have the same receiver as the data will. Any equalization is applied to the strobe as well as the data. - Walter: Even though the data pattern is 010101, and peaking filters don't do anything with that, and DFE doesn't do anything productive with it, they want the same equalization on the DQS as the DQ so they don't introduce any additional skew. - Probably train on DQ and then introduce the same equalization on the DQS. - It's basically a waste of power to have equalization on the DQS. - Randy: Fangyi had talked about some potential common mode issues. I asked him to attend the ATM call to discuss the concerns. - Walter: It is true that there are common mode issues that the EDA tool has to deal with very carefully. - This is for the EDA tool to deal with, not the model. - Arpad: If it turns out that there is nothing we need to add to the spec from the algorithmic point of view, then will we need any new "logistics" parameters to help deal with the timing issues and the fact that we have data and clock on separate lines? - Walter: Likely no. - Randy: Probably similar to how there's lots of timing in current DDR specs, but it's up to the EDA tool to do it. - Arpad: Currently, when we run an AMI simulation we make an eye using clock ticks returned by the receiver that models the CDR. - How is that done if you have separate clock and data lines? - Walter: I'd like to answer that, but I'm not sure people on JEDEC have resolved it. - There is still disagreement on fundamental issues in the DDR5 spec. - As soon as DDR5 has been standardized we can write a BIRD to handle it. BIRD 189: - Walter: I'd like to talk about packaging. - Many of us have been in the packaging meetings. - The BIRD has been finished and submitted. - There will be an update with errata and improved graphics but no substantive change yet. - I think it's important that every EDA vendor review the BIRD to make sure it is well defined enough that they can implement it. - It's also important that every IC vendor that delivers package models make the following judgement, "I am currently making package models for customers that need broadband package models. Can I use these same models with this new syntax?" - Arpad: I have a question for Randy. - Randy, in your package models you usually provide an on-die decoupling subcircuit. - Would that kind of modeling also be supported with this new BIRD 189? - Randy: Yes, as long as the on-die decoupling is IBIS-ISS compliant or is a Touchstone you can wrap it up in a package or on-die interconnect model and BIRD 189 will fully support that. - Arpad: You often provide a full chip decoupling model and per DQ model. - Would they both work? - Randy: I think you could decide if you wanted to include a more detailed on- die interconnect model for the PDN, then you could use the per DQ decoupling models to show where they actually attach to the PDN. - Otherwise, if you don't need that kind of detail, the full chip decoupling model is probably quite sufficient. - Arpad: Would you see the need to continue supplying the two types? - If so, is there an easy way to select one approach or the other? - Would you need two completely different models for per DQ vs. overall? - Randy: I'd probably need two separate models available through a selector if I really wanted to have both. - I'd probably just choose one or the other approach when I created the model. - Walter: I'd like to get better coverage and review by IC vendors in general. - There are only two things in the BIRD that I'm not happy about. One is: - The requirement that if we split models between the on-die interconnect and the package interconnect so that the models are really in two separate files, they have to be concatenated together in one model set. I'd like to be able to put the on-die models in one interconnect model set and the package interconnect models in another set. The BIRD does not actually prohibit that, but it does "strongly recommend" that they be put in the same interconnect model set. I think "strongly recommend" is too strongly worded. I think it can be inconvenient to do that, particularly for memory and FPGA vendors, and I would like more flexibility. - Bob M.: I would generally support more independent representation of the models in IBIS files as opposed to linking them all together. Linking has generally caused problems for us in getting the data associated with the right Tx, Rx, and IBIS file when things are mixed and matched all over. Being able build a model for an Rx, and embed it in an IBIS file, and have an AMI file for it and package it all up as an Rx is more useful for me. - Walter: You would like to have the package model as part of the AMI file? - Bob: I'm not sure. - I tend to view the package as part of the channel as opposed to part of the Tx or Rx. That's because I'm doing ASICs as opposed to standard parts. - Walter: That's one reason. The other reason is that you can't put these broadband package models in an IBIS file right now. The only way you can do it is by putting it in the channel. - That's one of the reasons we implemented this. - I could look at one of your examples and demonstrate how to take one of those package models that you normally put in the channel and incorporate it into the IBIS file. If that gets far enough we could show the example to the ATM. - Bob: Okay. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Bob Ross to submit BIRD 186.1 to the Open Forum. AR: Arpad to email the Open Forum regarding BIRD 186.1. AR: Arpad to email the Open Forum regarding BIRD 147.6. ------------- Next meeting: 21 February 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives